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Why  Model? 

A  model  is  a  set  of  statements  in  some  modeling  language  made 
about  some  system  or  domain. 

-  Standard  modeling  languages:  Unified  Modeling  Language  (UML), 
Business  Process  Modeling  Notation  (BPMN),  Systems  Modeling 
Language  (SysML),  Service  Oriented  Architecture  Modeling  Language 
(SoaML),  etc. 

A  model  may  be  used  to  describe  a  domain  or  system  under  study  or 
to  specify  a  (business,  software  and/or  hardware)  system  to  be  built. 

-  Descriptive  models  are  generally  used  for  analysis. 

-  Specification  models  are  generally  used  for  engineering. 

Models  are  intended  to  represent  and  communicate  the  results  of 
analyses  and  proposals  for  new  syntheses. 

-  No  model  can  represent  everything  -  but,  to  be  useful,  a  model  must 
effectively  promote  general  understanding  and  communicate  important 
details. 


Why  Execute  Models? 

A  model  may  specify  the  behavior  of  a  system,  that  is, 
how  the  system  interacts  with  external  entities  and 
changes  its  state  over  time. 

A  behavioral  model  is  executable  if  it  is  complete 
enough  that  the  specified  behavior  can  be  enacted  or 
simulated  by  an  automated  execution  tool. 

Model  execution  may  be  used  to: 

-  Explore  possible  (desirable  and  undesirable)  behaviors  of 
system 

-  Validate  the  behavioral  specification  for  a  system 

-  Actually  act  as  the  implementation  of  the  system 
(particularly  for  business  processes  or  software  systems) 


Modeling  for  Software  Development 

How  it  usually  works  without  executable  models 


Architects  give  models  to  developers 


Architects 
create  the 
models 


Ishi—  • - 4 


Developers 
create  artifacts 
based  on  the 
models 
(maybe) 


But... 


Developers  provide  feedback  to  the  architects 
(maybe) 


•  It  is  hard  to  validate  the  correctness  of  the  models  before  development. 

•  The  developers  may  not  follow  the  models,  without  providing  feedback. 

•  It  is  hard  to  keep  the  models  and  development  artifacts  in  sync  during 
development  (and  maintenance). 


Executable  Modeling  for  Software 

Development 


How  it  works  with  executable  models 


Technologists 
specify  the 
implementation 
platform 


Architects 
create  the 


models 


Using  a  standard- 


conforming  UML 
modeling  tool 


Architects  validate  the  models  by  executing 
them  in  a  simulated  test  environment 


The  models  are  provisioned  as  executing 
artifacts  on  the  target  platform 


The  models  are  the  source  code. 


Executable  Modeling  for  System 

Engineering 


Using  a  standard- 
conforming  SysML 
execution  tool 


System 
engineers 
create  the 
models 


Using  a  standard- 
conforming  SysML 
modeling  tool 


System  engineers  analyze,  simulate  and 
validate  the  system  design,  and  allocate 
requirements  to  components. 


Execution  artifacts 
could  include: 

•  System  behavior 

•  Timing 

•  Statistics 


Models  can  include  both 
hardware  and  software 
components. 


Hardware  and  software  engineers  develop 
components  to  satisfy  the  requirements. 

Test  engineers  develop  the  test  environment  to 
verify  the  requirements. 


What  is  SoaML? 


An  OMG  Standard  for  Modeling  Service  Oriented  Architectures 

-  Adopted  from  the  UML®  Profile  for  Modeling  Services  (UPMS)  RFP 

-  SoaML  supports  the  "A"  in  SOA 

-  Used  for  modeling  SOA  at  the  business,  enterprise  and  technology  levels 

-  Leverages  Model  Driven  Architecture 

A  "Profile"  of  the  Unified  Modeling  Language™ 

-  Can  be  used  with  off-the-shelf  UML  tools  as  well  as  customized  tooling 

In  the  "finalization"  stage  of  the  OMG  process  -  essentially  an  adopted  "beta" 
specification 

-  Finalization  with  minor  clean-up  expected  to  complete  this  year 

Tool  support  &  implementations  already  exist 

-  Tool  support  -  making  it  easy  to  create  services  models 

-  MDA  Implementations  -  provisioning  web  services,  business  artifacts  and  implementations 
from  SoaML  models 


Context  for  Enterprise  SOA 


MDA 

Terms 


Business  Model 


Enterprise  Services  (e-SOA) 

Roles,  Collaborations  &  Interactions 
Process,  Information  &  Rules 


Logical  System  Model 


Technology  Services  (t-SOA),  Components, 
BPM 

Interfaces,  Messages  &  Data 


Technolo&v  Specification 


JMS,  JEE,  Web  Services,  .NET 
WS*,  BPEL,  XML  Schema 


Relating  the  Parts  for  Model  Driven 


Value  derived  from  the  architecture 

with  MDA 


i 


Component 

Acquisition 

Specification 


OMB  300 


FEA/FTF 

BRM 
SRM 
DRM* 


Business  Concerns 


Business  Model 


Enterprise  Services  (e-SOA) 
Roles,  Collaborations  &  Interactions 
Process  &  Information 


Loaical  Svstem  Model 


Technology  Services  (t-SOA), 
Components,  BPM 
Interfaces,  Messages  &  Data 

Technoloav  Specification 


JMS,  JEE,  Web  Services 
WS*,  BPEL,  XML  Schema 


Web  Services 


Test  & 
Simulation 


Components  j- 


Adapters  |_|- 

Deployment 

Data 

Business  Driven  Technology 
Facilitating  Business  Processes 


System  Modeling 


Real  World 


Math  Models 


si 


Difference 

Equations 


Algorithms 


Each  transition  point 
introduces  constraints 
and  assumptions 


Architecture 


System  Modeling 


Real  World 


Sample 

Domains 

Sample  Constraint 

Sample  Assumption 

Airborne 

Non-Linear  PDE/DE 

Coordinate  System  selection 

Medical 

Conceptual  Data  Model 

Handles  Data  &  Images 

Information 
Technology  (IT) 

Conceptual  Data  Model 

Handles  Data  &  Images 

System  Modeling 

Math  Models 


Difference 

Equations 


Sample 

Domains 

Sample  Constraint 

Sample  Assumption 

Airborne 

Non-Linear  PDE/DE 

Approximation  Non-Linear 
System  of  Equations 

Medical 

Step  not  applicable 

Step  not  applicable 

Information 
Technology  (IT) 

Step  not  applicable 

Step  not  applicable 

System  Modeling 


Difference 

Equations 


Sample 

Domains 

Sample  Constraint 

Sample  Assumption 

Airborne 

Non-Linear  PDE/DE 

Approximation  Non-Linear 
System  of  Equations 

Medical 

Step  not  applicable 

Step  not  applicable 

Information 
Technology  (IT) 

Step  not  applicable 

Step  not  applicable 

System  Modeling 


Algorithms 


Sample 

Domains 

Sample  Constraint 

Sample  Assumption 

Airborne 

Decisions  on  Packaging 

Level  of  Fidelity  and  error 
propagation  rate 

Medical 

Logical  Data  Models 

Data  &  Images  representations 

Information 
Technology  (IT) 

Decisions  on  Packaging 

Acceptable  response  time 

Architecture  Element 


Where  the  rubber  meets  the  road:  Partitioning 


Partitioning  driven  by: 

1.  Packaging  of  Algorithms 
Into  "Physical"  Items 

2.  Interfaces  determine 
packaging  of  Algorithms 
into  "Physical"  Items 


Integration  strategy 
determines  packaging  of 
Algorithms  into  "Physical" 
Items 


Accommodates: 

•Distributed  or  Centralized 
Enterprise  or  Embedded 
•Real-Time  or  Non-Real-Time 
•Homogeneous  or  Heterogeneous 
•In  a  Chip  or  In  the  "Cloud" 


Architecture  Element 

Battle  begins  with  Domain  Allocation  and  Granularity 


Partitioning  driven  by: 

1.  Packaging  of  Algorithms 
Into  "Physical"  Items 

2.  Interfaces  determine 
packaging  of  Algorithms 
into  "Physical"  Items 


3. 


Integration  strategy 
determines  packaging  of 
Algorithms  into  "Physical" 
Items 


Accommodates: 

•  Hardware,  Software 
and/or  Firmware 

•  Functions,  Objects 
and/or  "Services' 


j; 


Example  Enterprise  Level  SOA 
Claims  Processing  Services  Architecture 


r  \ 

f  X 

A  services  architecture  describes  how  participants  work 

A  participant  represents  some  party  that  provides 

together  for  a  purpose  by  providing  and  using  services 

and/or  consumes  services.  Participants  may 

expressed  as  service  contracts.  It  is  modeled  as  a  UML 

represent  people,  organizations  or  systems. 

collaboration. 

L  J 

-^<ServicesArchitecture» 

RIB  Claims  Processing 


«Participant» 

applicant :  Applicant 


«ServiceContract» 

:  Query  for  SSN 

"  I 

querier 1 


J 


responder 


«Participant» 

idervt :  SSN  Matcher 


X 


applicant 


«ServiceContract» 

:  Apply  for  RIB 


handler 


«Participant» 

handler :  Claims  Handler 


A  service  contract  is  the  specification  of  the 
agreement  between  providers  and  consumers  of 
a  service  as  to  what  information,  products, 
assets,  value  and  obligations  will  flow  between 
them.  It  specifies  the  service  without  regard  for 
realization,  capabilities  or  implementation. 


consumer 


«ServiceContract» 

:  Establish  RIB  Claim 


provider 


«Participant» 

processor  :  RIB  Claims  Processor 


Linking  messages  to  business 

information 


«MessageType» 

Find  Principals 

-type :  String  [0..1] 
-any  key  :  String  [0..1] 
-name :  String  [0..1] 
-role  type  :  String  [0..1] 


«MessageType» 

Principal  Detail 

-principal :  Principal 


«MessageType» 

Principal  List 

-principal  list :  Principal  Detail  [*] 


«MessageType» 

Role  Types 

-role  types  :  Role  Type  [*] 


SOA  Messages  can 
reference  and  include 
parts  of  the  logical 
information  model  - 
forming  a  connection 
between  SOA  and 
enterprise  data 


Contact  Information 

♦isPrimary  :  Boolean  =  false 

- ST - - 


fVbnaged  information 

«Property»+rtdentifier :  String  [0..1]{readOnly,islD} 
-|>+date  information  created  :  date  [1]{readOnly} 

+date  information  changed :  date  [0..1]{readOnly} 
+deactivated  :  Boolean  =  false{readOnly} 


«Entity» 

Role  Type 

+description :  String 
-role  type  1 


{-contact  information 

Contactabfe 

f 

1 

"2T 


«Entity» 

Principal 


-role  of 
1 


+legal  name :  String 

+date  principle  created  :  date  [0..1] 


-has  roles 


T5- 


0..1  -associated  with 


«Errtity» 

Role 


-associates 


Organization 

+tax  ID :  String  [0..1] 

+DUNS  ID:  String  [0..1] 

+date  founded  :  date{redefines  date  principle  created} 


Person 

+SSN:  String  [0  .1] 

+birth  date  :  "date{redefines  date  principle  created} 


Realizing  the  Model 

How  to  we  use  I.T.  to  realize  our  processes  and  services? 

-  Direct  execution  frameworks 

•  The  "no  code"  approach  where  the  process  and  services  execute  directly 
from  the  model 

•  May  use  other  standards,  such  as  BPEL 

-  Wrapping  and  adapting  existing  capabilities 

•  Automatic  or  manual  creation  of  "adapter  components"  that  use  legacy 
systems,  information  or  services  to  create  the  architected  enterprise 
services 

-  Creation  of  new  application  components  and  services 

•  Build  new  capabilities  by  creating  new  components  and  creating 
composite  applications 

•  May  be  visual  and  declarative  or  code  oriented 

Under  the  SoaML  framework,  all  of  these  options  can  co-exist 
as  a  system  of  systems  linked  by  services 


Intersection  of 
System  Modeling  &  SOA 

•  Both  require  an  Integration  Strategy 

•  Both  require  the  equivalence  of  "services"  at 
some  level 

•  Both  can  accommodate  commercially 
available  frameworks 


Issue  to  be  solved  is  finding  the  appropriate  granularity  of 
"services"  that  allows  us  to  "Construct"  systems 


The  Affordability  Challenge 


Processes,  Procedures,  'Methodologies 


Proposals,  Contracts,  'Services  \y 


Backup  Information  on 
System  Modeling 

Architecture  Element  "X" 

Decomposition  of  Architecture  Element  "X 
Establish  Structural  Model  Framework 

-  Import  Mechanism 

-  Control  Mechanism 

-  Export  Mechanism 

Construct  Test  Scenarios  and  Capture  Test 
Results 


Architecture  Element 

Battle  begins  with  Domain  Allocation  and  Granularity 


Partitioning  driven  by: 

1.  Packaging  of  Algorithms 
Into  "Physical"  Items 

2.  Interfaces  determine 
packaging  of  Algorithms 
into  "Physical"  Items 


Integration  strategy 
determines  packaging  of 
Algorithms  into  "Physical" 
Items 


Accommodates: 

•  Hardware,  Software 
and/or  Firmware 

•  Functions,  Objects 
and/or  "Services" 


Architecture  Element  "X"  Decomposition 


Information  Flow 


Structural  Model  Framework 


Structural  Model  Framework 


